All committers have signed the CLA.

cc: @rgbkrk

I'm sure others are more familiar with the latest for how to serialize functions / modules to run clientside. Currently I have this hack:

// Create an anywidget module (export a "render" function) for the front end
// The `model` is synchronized with `update` messages sent from the comm_msg
let esm = `export ${async function render({ model, el }) {
  let { default: confetti } = await import ("https://esm.sh/canvas-confetti@1.6.0");
  model.on("change:value", () => confetti({ angle: model.get("value") }));
  confetti();
}.toString()}`;

But anywidget, just expects you to ship ESM that exports a function called render. The render function gives you access to a model which you can listen for and emit updates to state for objects that live in the kernel.

More details.

Works with updates to the frontend. Would be awesome to be able to listen for messages from the frontend as well (i.e. enabling 2-way data binding). Not sure that is implemented yet.

This is awesome, I'm glad you were able to make this fly so quickly. Thank you!

Would be awesome to be able to listen for messages from the frontend as well (i.e. enabling 2-way data binding). Not sure that is implemented yet.

That's #20592. It would be nice to have the Javascript API for it that we want to expose that is as close to one of the many web standard options (to be Deno-y).

You're making me realize we probably need to support the Jupyter message buffers as the final optional argument of this big broadcast message.

Roughly we're looking at an overall interface of:

type DenoJupyter = typeof Deno & {
  jupyter: {
    broadcast(
      msg_type: string,
      content: { [key: string]: object },
      metadata?: { [key: string]: object },
      buffers?: ArrayBuffer[]
    ): Promise<void>;
  };
};

It would be nice to have the Javascript API for it that we want to expose that is as close to one of the many web standard options (to be Deno-y).

Yes! I have some ideas.

You're making me realize we probably need to support the Jupyter message buffers as the final optional argument of this big broadcast message.

Indeed.

The other option would be to have a single object for other possible message data. Not sure if the other fields could be something we'd expose in the future.

type DenoJupyter = typeof Deno & {
  jupyter: {
    broadcast(
      msg_type: string,
      content: { [key: string]: object },
      extra?: {
        metadata?: Record<string, object>,
        buffers?: ArrayBuffer[]
      }
    ): Promise<void>;
  };
};

I just merged #20710, can you please rebase the PR @manzt?

The other option would be to have a single object for other possible message data. Not sure if the other fields could be something we'd expose in the future.

This seems like a reasonable solution to avoid balooning number of arguments this API accepts.

Not sure if the other fields could be something we'd expose in the future.

parent_header is controlled by the Deno kernel, header we also shouldn't muck with.

Famous last words and all, the jupyter spec will not extend the body of the message beyond what is there with parent_header, header, content, metadata, and buffers.

I'm totally cool with extra though. 😄

I just merged #20710, can you please rebase the PR @manzt?

Done, @bartlomieju! (TIL git cherry-pick 😅)

I'm totally cool with extra though. 😄

Okay, how about we introduce extra in this PR, but just with optional metadata? Sound OK?

It's nice to have the explicit names (as well as the option to extend extra if necessary in the future for whatever reason).

Deno.jupyter.broadcast(
  "comm_open",
  {
    "comm_id": "blah",
    "data": {
      "method": "update",
      "state": { "value": null },
      "buffer_paths": [["value"]]
    }
  },
  {
    metadata: { "version": "2.1.0" },
    buffers: [new Uint8Array([1, 2, 3, 4, 5]).buffer]
  }
);

I doubt the API would explode with the positional arguments, but this way the ordering of arguments isn't important. Since metadata or buffers could be sent independently of each other, it's also nice to not need to pass explicit undefined to the API:

Deno.jupyter.broadcast(msgType, content, undefined, buffers);

vs

Deno.jupyter.broadcast(msgType, content, { buffers });

done!

Implemented a mod.ts in anywidget @rgbkrk . (Think I might have messed up the denoland webhooks, since it's a monorepo and I'm not sure how to specify release for the packages/anywidget/mod.ts path).

import { widget } from "https://raw.githubusercontent.com/manzt/anywidget/main/packages/anywidget/mod.ts";

let model = await widget({
    // shared model between frontend and backend
    state: { value: 0 },
    // front-end render function
    render: ({ model, el }) => {
        let h1 = Object.assign(document.createElement("h1"), {
            innerText: "Value is " + model.get("value"),
        });
        model.on("change:value", () => {
            h1.innerText = "Value is " + model.get("value");
        });
        el.appendChild(h1);
    }
});

model

for (let i = 1; i <= 10; i++) {
    model.set("value", i);
    await new Promise(resolve => setTimeout(resolve, 500));
}

Wrote a way to do imports with the anywidget in manzt/anywidget#311